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Abstract— As one of the most popular blockchain systems, 
EOSIO has been widely used in decentralized applications 
(DApps). Compared with traditional proof-of-work (PoW)-based 
blockchain systems like Bitcoin, EOSIO achieves a high trans- 
action throughput and an alleged decentralization with the 
Delegated Proof-of-Stake (DPoS) consensus protocol. However, 
recent reports claimed the existence of voting collusion and 
manipulation during the DPoS consensus procedure of EOSIO, 
which may greatly decline the decentralization degree, fault 
tolerance, and reliability of the whole system. In this article, 
we obtain data from up to 135000000 blocks of EOSIO and 
conduct a data-driven decentralization analysis. Specifically, 
we characterize the decentralization evolution of the two phases 
in DPoS, namely block producer election and block production. 
Moreover, we study the voters with similar voting behaviors and 
propose methods to discover abnormal mutual voting behaviors 
in EOSIO. The analysis results show how EOSIO gradually 
evolves from decentralization to oligopoly and our methods can 
effectively capture abnormal voting phenomena in the EOSIO, 
which can also provide important insights for the design and 
maintenance of other DPoS-based blockchains. 


Index Terms— Blockchain, decentralization, delegated proof- 
of-stake (DPoS), EOSIO, network analysis. 


I. INTRODUCTION 


OWADAYS, blockchain [1] has aroused great attention 

among people and has been widely applied in many 
fields such as finance, healthcare, and the Internet of Things. 
Technically, blockchain is an append-only distributed ledger 
database based on multiple techniques like peer-to-peer net- 
works, cryptography, and consensus mechanisms. Different 
from traditional centralized systems, blockchain provides users 
a decentralized environment that can avoid the single-point 
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failure of a system. Thus decentralization is a core element 
in blockchain networks and plays an important role in the 
security and reliability of the system. 

Based on the Proof-of-Work (PoW) consensus protocol [2], 
Bitcoin [3] and Ethereum [4] are regarded as two of the 
most famous blockchain systems. However, both Bitcoin and 
Ethereum suffer from the problem of low scalability and can- 
not meet today’s growing demand for applications. Different 
from traditional PoW-based blockchain systems, EOSIO [5] 
adopts a more efficient consensus protocol—Delegated Proof- 
of-Stake (DPoS) [6] and a novel architectural design. The 
consensus process in EOSIO can be briefly summarized into 
the block producer election phase and the block production 
phase. It concentrates the block production process in the 
hands of a small set of block producers (also called super 
nodes) elected by the entire network, and thus improves 
the transaction throughput. As one of the earliest and most 
typical DPoS-based blockchain systems built for a large scale 
of commercial decentralized applications (DApps), EOSIO 
was once considered the representative of blockchain 3.0 [7]. 
In addition, EOSIO successfully outstripped Ethereum in 
DApp transactions during its first three months after its 
launch [8]. 

Out of the importance of blockchain security, recently many 
efforts have been devoted to analyzing the decentralization 
in different blockchain systems [9]-[11]. Intuitively, if a 
blockchain system is not decentralized enough, it may be 
easily controlled by a small minority of parties. In this case, 
the blockchain system is fragile and cannot ensure the facticity 
of the ledger records when facing threats like 51% attack [12] 
and selfish mining [13]. Although EOSIO advertised that its 
block production mechanism is very decentralized when it 
launched, recent reports pointed out that the distribution of 
block producers has been centralized in a specific group that is 
in close collaboration [14], [15]. This fact indicates that since 
the debut of EOSIO in 2018, the decentralization of EOSIO 
has changed significantly. 

Existing studies of EOSIO include performance analysis [7], 
security analysis on system and smart contracts [16], [17], 
transaction data analysis [8], [14], [18] and so on. However, 
few studies have considered the issue of decentralization evo- 
lution in EOSIO. Though some studies measured the decen- 
tralization of DPoS-based blockchain systems with Shannon 
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entropy [19], [20] and pointed out several clear vulnerabilities 
of EOSIO from a theoretical view [7], there is still a lack of 
study to capture and reveal the abnormal voting phenomena 
such as malicious voting collusion from the on-chain data. 
Thus unlike existing work which usually evaluates the decen- 
tralization of blockchain systems from a theoretical and static 
view, in this study, we conduct a data-driven and evolutionary 
analysis with the blockchain data from EOSIO. 

The overall framework of this article is shown in Fig. 1. 
First, we collect the blockchain transaction data by running an 
EOSIO full node and replaying all transactions. Our dataset 
consists of data from up to 135000000 blocks. Second, 
based on the data, we quantify the decentralization of EOSIO 
from an evolutionary view. We characterize the activities of 
voters, voting proxies, and block producers during the DPoS 
consensus process, and find that EOSIO gradually evolves 
from decentralization to oligopoly during the observation time. 
We further investigate the abnormal voting behaviors that may 
affect the decentralization and propose methods to reveal the 
voting gangs with similar voting behaviors and mutual voting 
behaviors from voting relationship analysis. 

Finally, we try to answer two questions according to the 
analysis results: 1) what is the root cause of the oligopoly 
trend and voting anomalies in EOSIO? and 2) how can we 
adjust the DPoS consensus mechanism to make the system 
more decentralized? Combining the time period covered by 
the collected data, the comparison between voting proxies in 
EOSIO and mining pools in Bitcoin, and the cost of voting 
manipulation, we draw a conclusion that the system design is 
more likely to be the root cause rather than the bootstrapping 
phase. We introduce some feasible solutions to improve the 
DPoS consensus mechanism, such as adjusting the number 
of votes allowed per account and assigning different voting 
weights to the multiple chosen candidates based on rating. 
In summary, we make the following contributions in this 
article. 


1) To the best of our knowledge, our work is the first data- 
driven study on the decentralization evolution of EOSIO. 

2) We develop methods for detecting abnormal voting 
gangs in EOSIO and apply them to perform a network 
analysis of voting relationships. 

3) Based on our analysis, we discuss the root cause of the 
oligopoly trend and how to increase the decentralization 
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degree in EOSIO, which can provide a reference for 
other DPoS-based blockchains. 


The remaining sections of this article are organized as fol- 
lows. Sections II and II introduce the research background and 
detail the data collection procedure. Sections IV and V next 
introduce the decentralization measurement study and analysis 
of the abnormal voting phenomena. Section VI discusses two 
questions according to our findings and Section VII provides 
the related work. Finally, we conclude the article and discuss 
the future work in Section VIII. 


II. BACKGROUND 


In this section, we provide the background required to 
understand the operation mechanism of EOSIO and the DPoS 
consensus mechanism in EOSIO. 


A. Accounts and Transactions in EOSIO 


Unlike Ethereum, the identity of an account in EOSIO is a 
human-defined string with up to 12 characters in length. Each 
account is created by an existing account via the newaccount 
interface and can deploy a contract on itself via the setcode 
interface of the system account “eosio.” The main currency 
circulating in EOSIO is EOS tokens, and resources of smart 
contracts such as CPU and RAM can be obtained via EOS 
token mortgage. A transaction in EOSIO contains multiple 
actions, and each action corresponds to an invocation of a 
contract. According to the initiator in contract invocation, 
these actions can be divided into calling actions and inline 
actions, and they are called by users and triggered by contracts, 
respectively [7]. In addition, EOSIO provides flexible role- 
based permission management allowing users to delegate their 
permissions to achieve high-level control on other users. 


B. DPoS and DPoS in EOSIO 


The DPoS consensus mechanism has become increasingly 
popular and is widely adopted in blockchain systems such as 
EOSIO, Tron [21] and BNB Chain [22]. Instead of solving 
the PoW puzzles, DPoS decides its block producers according 
to the votes of the entire stakeholders, thus achieving high 
scalability in block production. The DPoS consensus mech- 
anism consists of the block producer election phase and the 
block production phase, and the details of these in EOSIO are 
provided as follows. 

1) Phase I (Block Producer Election): This phase elects 
21 block producers for block production. To become a block 
producer candidate, anyone in EOSIO who possesses enough 
hardware resources and the full ledger data can register via the 
regproducer interface of “eosio.” Then the top 21 candidates 
with the highest voting weight can become block producers 
and obtain block production rewards. 

Anyone in EOSIO can vote for the block producer candi- 
dates in two ways. The first way is voting directly through 
setting the producers parameter of the voteproducer interface 
as the list of at most 30 selected candidates. The second way 
is voting through a proxy by setting the proxy parameter of 
the voteproducer interface as the chosen proxy, and then the 
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proxy can vote for block producer candidates on behalf of all 
proxied users. A user can register to become a voting proxy by 
setting the isproxy parameter of the regproxy interface as 1, 
otherwise, a user can cancel the registration by setting the 
isproxy parameter as 0. 

The voting weight of a voter is related to the voting time 
and the staked tokens for CPU and bandwidth, which can be 
calculated as 


weight = 10000 x stake x 2'"¢* (1) 


where stake is equal to the amount of delegated bandwidth and 
computation, and index can grow incrementally every week if 
voters update their voting, calculated as: index = (1/52) x 
L(tvote — finit)/(7 X tday)]. In this formula, tore represents the 
Unix timestamp when a user performs the voteproducer oper- 
ation, finit represents the Unix timestamp of 1 January 2000, 
and fgay denotes the number of seconds per day. As we can 
see, with the same amount of stakes, the voting weight of 
recent votings is higher than that of earlier votings. This design 
can encourage voters to keep their votes updated. Moreover, 
once a user updates the number of stakes via delegatebw 
(increase mortgage) or undelegatebw (reduce mortgage), the 
voting weight will be automatically updated. For a voting 
proxy, its voting weight is the sum of the voting weight 
owned by all proxied voters. If a voter votes for multiple 
candidates, each chosen candidate can receive an equal vot- 
ing weight according to the stakes and voting time of the 


voter. 
2) Phase 2 (Block Production): In this phase, the elected 


21 block producers from the block producer election begin 
a round of block production on behalf of the stakeholders 
in EOSIO. They validate the transactions, construct the valid 
transactions into blocks and then produce blocks orderly. Each 
elected block producer has a fixed 3 s to produce six blocks. 
Therefore, a round of block production lasts 63 s. If a block is 
not produced at the scheduled time because of network delay 
or other reasons, this block will be skipped and will not affect 
the subsequent block production. The new block confirmation 
process is also conducted among the 21 block producers. Once 
a new block is confirmed by more than 2/3 of the block 
producers (i.e., at least 21 x 2/3 + 1 = 15 block producers) 
through signed messages, this block will be appended to the 
blockchain. With DPoS, EOSIO can generate a new block 
every 0.5 s averagely with a throughput of up to 8000 transac- 
tions per second (TPS) [8], which achieves higher performance 
than many other blockchain systems. 


III. DATA COLLECTION 


We conduct our experiments on up to 135000000 blocks 
in EOSIO, which cover the transaction data from 8 June 
2018 to 5 August 2020. To measure the decentralization of 
EOSIO, we collect three types of blockchain data, includ- 
ing block header, transaction actions, and the voting weight 
data by running an EOSIO full node and replaying all 
transactions. The dataset is available on the XBLOCK.PRO! 
website. 


"http://xblock.pro/ 
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Fig. 2. (a) Number evolution and (b) staked token evolution of voters and 
all stakeholders. 
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1) Block Headers: The block header in each block provides 
a summary for the entire block, which includes informa- 
tion such as the block producer, the block timestamp, the 
transaction Merkle root, etc. We obtain the block header 
data by starting a core service daemon of EOSIO named 
Nodeos [23] to synchronize data on the mainnet. 

2) Transaction Actions: A transaction in EOSIO contains a 
set of actions, and each action is an invocation of a smart 
contract. However, only the calling actions are recorded 
in the blockchain, which are operations performed by 
users. While the inline actions, which are triggered by 
calling actions, are not recorded in the on-chain data 
and can be obtained only by replaying all transactions. 
To obtain the full transaction action data, we make 
use of the action trace data, which are the detailed 
run-time data of smart contract invocation generated 
by the Web Assembly Virtual Machine (WAVM). With 
history_file_plugin [18], we collect all action traces in 
JavaScript Object Notation (JSON) format. Then we 
extract the related actions such as delegatebw, undel- 
egatebw, regproxy, voteproducer, etc., from the action 
traces. 

3) Voting Weight Data: The voting weight received by each 
block producer candidate is in constant change since it is 
affected by the changes of voters and their stakes. Thus 
we calculate the voting weight data of each candidate 
by traversing the transaction actions and then record the 
data periodically. 


IV. DECENTRALIZATION MEASUREMENT STUDY 


In this section, we present a decentralization measurement 
study in EOSIO considering the processes of block producer 
election and block production. We try to characterize all 
voters, proxies, and block producers participating in the DPOS 
consensus process. Based on the analysis results, we reveal the 
evolution of decentralization and discuss some findings in the 
EOSIO network. 


A. Block Producer Election in EOSIO 


1) Overview of Block Producer Election: Based on the 
statistics of the collected dataset, we find out that there 
are a total of 2009168 accounts. Among these accounts, 
1739839 accounts have staked EOS tokens as stakeholders 
while only 84668 accounts have participated in the block 
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Fig. 3. (a) Staked token distribution of voters (the tokens of proxied accounts 
are accumulated on proxies) and (b) received voting weight distribution of 
block producer candidates, calculated at the end of the 135000000 blocks. 


producer election procedure as voters, occupying 4.87% of 
all stakeholders. The result indicates that only a small fraction 
of all stakeholders have taken part in the voting process. 

We then calculate the number evolution of accounts for 
voters and all stakeholders, as shown in Fig. 2(a). We found 
that the number of stakeholders and voters increase over time, 
but the number growth rate of voters is far short of the 
number growth rate of all stakeholders. This infers that many 
stakeholders do not care about the block production election, 
or even do not understand the voting mechanism in EOSIO. 
The power to decide who will become block producers thereby 
is held by a small number of stakeholders. Furthermore, from 
the amount evolution of staked tokens held by voters and all 
accounts shown in Fig. 2(b), we observe that the staked tokens 
held by voters account for half or less of the total network for a 
long time. Moreover, with the passage of time, the proportion 
of staked tokens held by voters increases. Since the waiver of 
trading fees in EOSIO provides a user-friendly environment, 
the DApp users will have less incentive to mortgage their EOS 
tokens. However, application developers, voters, and block 
producer candidates have a strong motivation to mortgage their 
EOS tokens. Especially, block producer candidates always 
canvass other stakeholders for electoral support to ensure their 
position, and thus the amount of staked tokens of the voters 
exhibits an increasing trend. 

2) Distribution Statistics: We investigate the staked token 
distribution among all voters and the received voting weight 
distribution among all block producer candidates. After map- 
ping the continuous values to 100000 equally spaced intervals, 
the distributions with a fitting line y ~ x~% are shown in 
Fig. 3(a) and (b). Both of the two distributions are in line 
with the power-law distribution, which indicates that a small 
number of voters hold a large amount of staked tokens, and 
a few block producer candidates have received a large voting 
weight. We then calculate the fraction of stakes held by the 
richest voters and find out that the top 5% of the voters possess 
more than 95% of the stakes. As for block producer candidates, 
the top 10% of the candidates have received more than 95% 
of the voting weight in the whole network. Hence, the voting 
resource is unevenly distributed among both voters and block 
producer candidates. As one of the security risks, most of the 
voting powers are concentrated in only a few rich voters so 
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(b) distribution of days participating in block production. 


that the voting results basically depend on a small number of 
voters. On the other hand, the extremely uneven distribution 
of received voting weight among block producer candidates 
can lead to the rich-get-richer phenomenon, also named the 
Matthew effect [24]. In the long run, it is easy to form block 
production oligopoly among the most popular block producers. 

3) Statistics of Voting Proxies: Although anyone who stakes 
EOS tokens can participate in the governance of EOSIO 
with their voting power, block producer candidates should 
be carefully chosen by considering some factors such as 
resources, community contribution, and location of block pro- 
ducer candidates. However, not every stakeholder has enough 
incentive to investigate different candidates and stays abreast 
of every new proposal in EOSIO, especially those who only 
hold a tiny amount of EOS tokens. 

Voting proxies are accounts that perform voting on behalf of 
other accounts. They vote for block producer candidates with 
voting power collected from proxied accounts and communi- 
cate to the proxied accounts which block producer candidate 
they choose. Each user can delegate its voting power to a 
voting proxy, and can also withdraw its voting power from the 
proxy at any time. In general, voting proxies can remove the 
high barrier of participating in governance for users and fully 
arouse the initiative of individual users, thereby increasing user 
participation in the voting process. 

According to our statistics, 1792 accounts have registered to 
become voting proxies, and 924 of them have been delegated 
as proxies via the voteproducer interface. It is worth noting 
that 40561 of the 84668 voters have voted through voting 
proxies, which means more than 47% of the voters execute 
their voting power via voting proxies. Fig. 4(a)-(c) show the 
account number evolution, staked token evolution, and voting 
weight evolution of all voters and proxied voters. By coop- 
erating with the corresponding value share evolution of the 
proxied voters in all voters in Fig. 4(d)-(f), the increasing use 
of proxies can be observed. Moreover, after May 2019, nearly 
70% of the voting weights are delegated to voting proxies. 
Under this trend, the votes of voting proxies can exercise 
considerable influence over the election results, since most 
of the voting powers are centralized in the voting proxies. 
A valuable research issue is whether there exist abuses of 
rights among the voting proxies, and we will discuss this issue 
in Section V. 
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Statistics about the proxied voters. (a)-(c) Account number evolution, staked token evolution, and voting weight evolution of all voters and proxied 


voters. (d)-(f) Value share evolution of the proxied voters in all voters for account number, staked tokens, and voting weights. 


Finding 1: Stakeholders increase rapidly with the boom 
of the EOSIO DApp ecology, but only a small number 
of them participated in the voting. The voting power is 
concentrated in a small number of voters. 

Finding 2: The received voting weights are unevenly 
distributed among the block producers, making it possible 


to form a block production oligopoly in the future. 
Finding 3: Proxies account for an increasingly large 
proportion of the total voting power. Though the use of 
proxies can arouse more stakeholders to participate in 
the consensus government, it also centralizes most of the 
voting power in a small part of the accounts. 


B. Block Production in EOSIO 


1) Overview of Block Production: When focusing on block 
production, we found that there are 615 accounts registering to 
become block producer candidates. Among these candidates, 
602 candidates have received voting weights from the voters 
and 62 candidates have become block producers. Fig. 5(a) 
shows the number evolution of block producers, and both the 
monthly number and accumulated number are given. Although 
the 21 elected block producers can be updated in each round 
according to their real-time voting weight, only around 25 dif- 
ferent accounts are elected as block producers each month. 
Moreover, the chosen block producers are relatively fixed after 
September 2019. 

Fig. 5(b) shows the distribution of days that block producers 
participate in block production, from which we can observe 
that about ten block producers participated in block production 
for more than 600 days during the 135000000 blocks which 
cover about 790 days. These statistics illustrate that despite 


a large number of candidates, the set of block producers has 
small variations. Many accounts participate in block produc- 
tion for a long term. Once these accounts are in collusion, 
it is easy to achieve double-spend attacks since EOSIO can 
only tolerate no more than 1/3 of malicious block producers. 
In theory, the block producers acting in malicious manners 
can be voted out. Yet in practice, block producers can earn 
considerable rewards in block production so that most of them 
possess a large number of EOS tokens and can become one 
of the largest stakeholders, making it even harder to vote the 
malicious block producers out. 

2) Quantitative Analysis With Information Entropy: Previ- 
ous studies have introduced the information entropy metric 
to quantify the degree of decentralization in block produc- 
tion [20], [25]. Here we adopt information entropy to compare 
the decentralization degree of different months. The informa- 
tion entropy metric for a month i, namely H(X;), can be 
calculated as follows: 


xj 
Pj = =r where x; € Xi (2) 
f Èj- 4j 7 
H(X) = — >) pj log Pj (3) 
j=l 


where X; stores the number of blocks produced by each pro- 
ducer in month i, x; denotes the number of blocks produced 
by block producer j, and n denotes the measuring range of 
top-n block producers. The greater the value of H (X;) is, the 
greater the decentralization degree is in the month since the 
block production is more random and disorderly. 

We display the quantitative results of information entropy 
in Fig. 6 by setting n = 10, 20, and the number of block pro- 
ducers in each month. From Fig. 6(a) and (b), we can observe 
that the information entropy of the first month is much smaller 
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Fig. 6. Evolution of the information entropy. Entropy with (a) n = 10, (b) n = 20, and (c) n = the number of all block producers. 


than that of the latter months for n = 10 and n = 20, which 
indicates that block production in the early days of EOSIO was 
more centralized among the top stakeholders. While as shown 
in Fig. 6(c), block production in months October 2018—April 
2019, July 2019, October 2019-July 2020 were also relatively 
centralized in general. Combining Figs. 6(c) and 5(a), we can 
infer that this phenomenon may be due to the less replacement 
of block producers in these months. 


Finding 4: Despite the relatively large amount of candi- 
dates, the set of block producers has small variations in 
general. 

Finding 5: In the early days of EOSIO, block production 


was centralized among the top stakeholders. While in the 
latest months, block production has been centralized in 
a specific group due to the small variations of the block 
producer set. 


V. EXPLORING THE VOTING GANG ANOMALIES 


In Section IV, the voting election and block production in 
EOSIO are characterized statistically. The obtained observa- 
tions have exposed some problems that may give rise to power 
centralization such as large stakeholders working together, 
proxies abusing their power, and block producers collud- 
ing. To further discover these associated abnormal voting 
behaviors, in this section, we first develop a voter clustering 
method to detect those who potentially work together and 
share their voting targets. After that, we discuss the mutual 
voting behaviors in EOSIO and propose methods to identify 
and analyze suspicious mutual voting relationships. 


A. Voter Clustering Analysis 


A great concern is that some large stakeholders can form 
alliances and communicate with each other before voting to 
solidify the positions of specific block producer candidates [7], 
causing voting manipulation and unfair competition. Accord- 
ing to the statistics given in Section IV-B, there are a total of 
615 accounts registering as block producer candidates. Since 
each voter can vote for up to 30 block producer candidates 
and the votes can be updated in each round, the probability 
that two voters often vote for two similar groups of candidates 
is relatively low. Therefore, voters who often support similar 


Algorithm 1 Voter Clustering Based on Similar Voting Behav- 

iors 

Input: The set of voters V, voting similarity S, selected 
threshold @. 

Output: A set of voter clusters with similar voting behaviors 
C; 

1: visited = Ø //visited marker 

2: C = //cluster set 

3: for voter v; in V — visited do 

4: add v; to visited 

5: Ci = {vi} 

6 No = {v €V,v! = vi|S (v, vi) = 0} 

7 for voter v; in No do 

8 if v; not in visited then 

9 add vj to visited 


10: add vj to Ci 

11: for voter vg € {v € V, v! = vj|S (w, vj) = 0} do 
12: add v; to No 

13: if len(C;) != 1 then 

14: add C; to C 


block producer candidates are more abnormal and likely to be 
motivated by common interests. 

1) Method Design: To group the voters which have similar 
voting behaviors into a cluster, we take the similarity of the 
historical voting records of voters into account. Firstly, the 
block producer candidates are numbered and the candidates 
voted by a voter u are recorded in a set R;(u) with a 
maximum length of 30 for sampling time i. Based on Jaccard’s 
coefficient, the voting similarity of voter u and v can be 
calculated as 
Deiat Riu) N Ri)! 
Diet |Ri@) U Ri(o)| 
where n is the sampling number. In the experiment, we record 
the voting results at the end of each month during 8 June 
2018-5 August 2020 and thus n = 26. Second, we propose a 
similarity-based voter clustering method that can automatically 
output the clusters with similar voting behaviors. Algorithm 1 
shows the pseudocode of the method, where the input contains 
the set of voters V, the voting similarity S, and a similarity 
threshold @. The set visited in the algorithm is used to mark 
the visited voters, and we treat each unvisited voter as a center. 
For each center, we select out voters whose voting similarity is 


S(u,v) = (4) 
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Fig. 7. (a) Three voting snapshots and (b) voting time distribution of the top ten detected clusters with the most staked tokens among the large stakeholders, 


where votes in the same cluster are assigned the same color. 


greater than or equal to @, add them to visited and the cluster 
that the center belongs to. And then, if a center v; has members 
behaving similarly in its cluster C;, voters who are similar to 
these members are also added into C;. Finally, the cluster C; 
is added to the output cluster set C. 

2) Detecting in Large Stakeholders: As mentioned in 
Section IV-A, the staked token distribution among all voters is 
extremely uneven. About 5% of the voters possess more than 
95% of the stakes in the statistics. Hence the votes of large 
stakeholders make a great effect on the governance of EOSIO. 
To investigate the abnormal large stakeholders with similar 
voting behaviors, we apply Algorithm 1 with 6 = 0.9 on 
the top 5% richest voters in the sampled voting records (the 
proxied stakes are accumulated on the proxies when ranking). 
And 88 clusters including 293 voters are detected from a total 
of 2723 voters. 

a) Voting snapshot and time distribution analysis: 
Fig. 7(a) displays three voting snapshots of the large stake- 
holders in the top ten detected clusters with the most staked 
tokens, where the y-axis depicts the index of the detected large 
stakeholders and the x-axis depicts the index of the candidates. 
If a voter y votes for block producer candidates x;—x3, then 
(x1, Y), (x2, y), and (x3, y) will be colored in the corresponding 
color of its cluster. From this figure, we can observe that voters 
in the same detected cluster have similar voting behaviors 
in both time and space, which can be illustrated by the 
very similar block producer candidates they support in these 
different snapshots. Fig. 7(b) shows the distribution of time 
when the large stakeholders in the top ten detected clusters 
with the most staked tokens operate the voteproducer action, 
where different clusters are assigned different colors. To our 
surprise, though the voters in the same cluster are grouped 
according to the sampled voting records, the voting actions of 
these voters occur at very similar timestamp sequences. 

b) Account creation relationship analysis: We further 
analyze the account creators of the detected voters, and 
visualize the relationships between account creators and the 
88 clusters in Fig. 8(a). In each edge of the figure, a target node 
represents a detected cluster of large stakeholders, a source 
node represents an account creator that creates one or more 
stakeholders in a cluster, and the edge thickness is related 
to the number of accounts created. From the figure, we can 
observe that most accounts in the same cluster are created 
by the same account, implying that these voters are likely 
to be controlled by the same entity and therefore they have 


Fig. 8. Relationships between account creators and the detected clusters, 
where clusters owning one account creator are colored red. (a) Large stake- 
holders. (b) Proxies. 


similar voting behaviors. Such kind of gathering phenomena 
in voting among large stakeholders can easily cause block 
production monopoly—the allies of these large stakeholders 
can obtain a solid position in the election. Moreover, they will 
earn more rewards (i.e., EOS tokens) from block production 
to consolidate their advantage in the election. 

3) Detecting in Voting Proxies: Voting proxies are accounts 
that can execute the voting power of proxied accounts. 
Recently, we have seen the rising use of proxies in voting. 
Usually, users delegate their voting rights to a proxy out of 
trust in the proxy’s voting decision. However, we can not 
exclude the presence of “selfish” proxies that only vote for 
their alliance members but do not consider the governance 
of the community. In this way, if users delegate their vot- 
ing power to these proxies, they will actually increase the 
competitiveness of a particular alliance and the degree of 
centralization. Therefore, there is an urgent need to understand 
the voting behaviors of voting proxies. Particularly, proxies 
having similar voting behaviors deserve our attention. And 
these proxies are suspected of being manipulated by the same 
entity and using different identities to attract the authorization 
of other stakeholders. To this end, we apply Algorithm 1 to 
all proxies in our dataset with 6 = 0.9. We totally detect 
35 clusters including 162 proxies. 

a) Voting snapshot and time distribution analysis: 
Fig. 9(a) and (b) visualize three voting snapshots and the 
voting time distribution of proxies in the top ten detected 
clusters with the most staked tokens, where different clusters 
are assigned different colors. Similar to the observations drawn 
from Fig. 7(a) and (b), the proxies in the same detected clusters 
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Fig. 9. 
votes in the same cluster are assigned the same color. 


vote for almost the same group of block producer candidates 
across time, and the time they operate the voteproducer action 
shows a convergent trait. 

b) Account creation relationship analysis: Fig. 8(b) dis- 
plays the account creation relationships between account 
creators and the 35 detected clusters, where a target node 
denotes a cluster of voting proxies and a source node denotes 
an account creator that creates one or more proxies in 
a cluster. As we can see, among 17 of the 35 clusters, 
proxies in the same cluster are created by one account. 
Furthermore, we observe that many proxies in the same 
cluster have common features in their account name. For 
example, proxies “hashfineos44,’ “hashfineosl4;’ “hashfi- 
neos33,” “hashfineos55,’ and “hashfineos13” have the com- 
mon prefix “hashfineos-” in their name, proxies “reallyreally,” 
“windowwindow,” “citycitycity,’ “familyfamily,’ etc., have 
reduplicated words in their name. We also observe that the 
account “octgenerator” creates 53 proxies detected in the same 
cluster, and all these proxies only vote for “oraclegogogo.” 
Though it is impossible to verify that the detected accounts in 
the same cluster belong to an entity due to the pseudonymous 
nature, the analysis results from multiple voting snapshots, the 
voting time distribution, and the relationships between account 
creators and the detected clusters indicate the abnormality of 
these addresses. 


B. Mutual Voting Anomaly Detection 


In this part, we aim to investigate the mutual voting anom- 
alies, which are suspected of trading votes and sharing the 
rewards of block production with gang members. We first 
propose and discuss three mutual voting patterns, and then we 
develop an algorithm to explore the potential mutual voting 
anomalies. 

1) Mutual Voting Pattern Analysis: As shown in Fig. 10(a), 
we consider three types of mutual voting patterns in the 
analysis: 1) linear-shaped pattern, in which two voters vote 
for each other directly to enhance their roles; 2) triangular- 
shaped pattern, where a voter a use a proxy to vote for 
another voter b and receive the vote back from the voter b; and 
3) eight-shaped pattern, in which two proxies and two proxied 
voters are involved and the two proxied voters vote for each 
other via proxies. Among these three kinds of mutual voting 
patterns, the linear-shaped pattern and the triangular-shaped 
pattern are relatively abnormal voting behaviors since there 
exist votes from non-proxy entities. 


0 
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(a) Three voting snapshots and (b) voting time distribution of the top ten detected clusters with the most staked tokens among the proxies, where 
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(a) Three mutual voting patterns and (b) their number evolution. 


Fig. 10. 


The number evolution of these patterns in different months 
is displayed in Fig. 10(b), and the occurring time of the mutual 
voting actions in each pattern is constrained to seven days. 
From the figure and the voting records, we obtain the following 
observations. 

1) Linear-Shaped Pattern: We observe that this most 
straightforward mutual voting pattern occurred mainly 
between some famous super nodes such as “eosnation- 
ftw,” “eoslaomaocom,” and “argentinaeos” in June 2018. 

2) Triangular-Shaped Pattern: The occurrence number of 
triangular-shaped patterns reached a peak in May 2019. 
By analyzing the voting records, we find that the occur- 
rence of this peak is related to the obvious mutual 
voting behaviors between “games.eos,’ “eos. fish; 
“starteosiobp,’ and “dilidilifans.” Firstly, the votes 
between “starteosiobp” and “eos.fish,’ “games.eos” and 
“eos.fish,’ “dilidilifans” and “eos.fish” are in triangular- 
shaped patterns with proxy “start13.io,’ “proxyfordili,” 
and “starteos.io,’ respectively. Secondly, “dilidilifans” 
and “games.eos,;’ “starteosiobp” and “dilidilifans,’ 
“games.eos” and “‘starteosiobp” are in eight-shaped pat- 
terns via their proxy, which provides further proof of the 
close relationship among these voters. 

3) Eight-Shaped Pattern: It occurs more frequently than 
the linear-shaped pattern and triangular-shaped pattern 
because voting proxies are active. The maximum occur- 
rence number peak of the eight-shaped pattern reached 
in October 2018, mainly caused by the frequently 
mutual voting of “acroeos12345” and “eoseouldotio” 
with a common proxy “votetochange.” This mutual 
voting relationship is natural since “acroeos12345” and 
“eoseouldotio” are both the organizers of the proxy 
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(a) (b) 


Visualization of (a) voting network and (b) near-clique anomaly. 


Fig. 11. 


“votetochange.”* For the second peak reached in May 
2019, we observe that there exists a large connected 
component formed by the mutual voting relationships 
of proxied voters. And among the 17 proxied voters 
in this connected component, the average clustering 
coefficient is 0.431 and 26 triangles are constructed by 
their relationships, indicating that these voters tend to 
gather together. 

2) Mutual Voting Gang Detection: To investigate the mutual 
voting gang anomalies, we build a voting network based on 
the voting actions, where each node denotes an account and 
each edge denotes the voting relationship between a pair of 
accounts. Then, we visualize the voting network by randomly 
selecting 5000 edges. As shown in Fig. 11(a), the voting net- 
work contains many hub nodes whose one-hop neighborhood 
(also named egonet) is in a near-star pattern and the one-hop 
neighbors are almost not connected. While for mutual voting 
gangs, more connections and higher relation intensity tend to 
exist within these gangs to maintain the status of the gang 
members. Therefore, there are some abnormal nodes whose 
one-hop neighbors are very well connected in the gangs, which 
can be described by the near-clique anomalies [see Fig. 11(b)]. 
And in the previous part, we have described three special cases 
of this anomaly. 

Based on this observation, we first define the voting inten- 
sity between a pair of nodes by taking the voting frequency, 
duration, and voting weight into account. The voting intensity 
from node i to node j (denoted by J;;) is calculated as 


Fij Ty Py 


1 
Ij => ¥*f ———_ + = + = _ 
3 Ženo) Fiu Dueno) Tuj Deng) Puj 


(5) 


where N(-) represents the neighbors of a node, F;; represents 
the voting frequency from i to j, 7;; is the cumulative voting 
time duration and Pj; is the average voting weight from i to j. 
The item about the voting frequency measures the willingness 
of i to vote to j, and the items about the voting time duration 
and average voting weight measure i’s voting share of j. 
We then assign a weight to each edge in the voting network 
to represent the voting intensity between a pair of nodes. And 
the weight w;; of the edge between nodes i and j is decided 
by the voting intensity from i to j and the voting intensity 
from J tol, Le., Wij = Ij + Iji. 


*https://www.alohaeos.com/vote/proxy/votetochange 
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Fig. 12. Visualization of the voting relationships in the detected cluster of 
“eoshuobipool,” where the accounts reported in [15] are labeled and assigned 
the color orange. 
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After obtaining the weighted voting network, we detect 
near-clique anomalies among the block producer candidates 
with the OddBall algorithm [26] and reconstruct the network 
by only keeping the relationships between the block producer 
candidates in the egonet of the detected accounts. Finally, 
we apply the Louvain algorithm [27] on the weighted network 
to detect suspicious voting gangs. The community detection 
results are obtained according to the voting intensity calculated 
by (5) and modularity optimization. After obtaining the clus- 
tering results, we weed out the accounts with only one edge 
in the reconstructed network since these accounts have less 
possibility to participate in voting collusion in their cluster. 
And the outputs are clusters with more than one node. 

Results: We obtain 11 abnormal voting gangs which totally 
include 334 nodes from community detection on the recon- 
structed network. In particular, we find out that a detected 
cluster, which includes 41 accounts, has 14 accounts coincid- 
ing with more than half of the accounts allegedly involved 
in mutual voting reported in [15]. The voting relationships in 
this cluster are shown in Fig. 12, where the detected labeled 
accounts and their relationships are assigned the color orange. 
As we can see in this figure, though there are some accounts 
having not been reported in [15], they have strong voting 
relationships with the cluster members. Furthermore, 24 of 
the 26 reported accounts have been detected in the output 
clusters. 

Moreover, we observed that there is a huge detected 
cluster consisting of 105 accounts. Among these accounts, 
102 are named in a regular pattern with “hayd” or “g44t” 
as the first four letters and “ge” as the last two letters, 
such as “haydiojxgege,” “haydiojygage,’ “g44tomrygige,” and 
“e44tomzugqge. And two of the last three accounts are cre- 
ated by two accounts in this naming rule. These observations 
illustrate that the method can help us notice some abnormal 
mutual voting gangs. 


VI. DISCUSSION 


Sections IV and V have presented a decentralization evo- 
lution analysis on EOSIO, a famous DPoS-based blockchain 
system, and reported some abnormal voting phenomena in the 
system. In this section, we attempt to answer two questions and 
provide insights into decentralization enhancement for EOSIO 
and other DPoS-based blockchain systems. 
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Newpool 
High profit, Zero risk 


Voting Philosophy Background 


Made the safest pool Newpool is the world's first decentralized pool without transfer 


Fig. 13. Introduction of a proxy belonging to the newpool decentralized 
staking pool on alohaeos.com, claiming that “High profit, Zero risk.” 


Q1: What is the root cause of the oligopoly trend and 
voting anomalies in EOSIO? The bootstrapping phase or 
the system design? 

We prefer to attribute the root cause of the oligopoly trend 
and voting anomalies in EOSIO to the system design. On the 
one hand, the EOSIO voting data studied in previous sections 
cover more than two years. The collected data include the most 
prosperous phase of EOSIO to date,? which is much longer 
than the bootstrapping phase. 

On the other hand, we find that voting proxies have recently 
become popular in the analysis. Some proxies even try to 
attract new users by claiming that delegating the voting power 
to them will result in high profit with zero risk, e.g., a proxy 
of new pool as shown in Fig. 13. These proxies are likely 
to grow into large staking pools, which not only violates the 
original design intention of voting proxies but also raises some 
security concerns similar to those brought by mining pools in 
Bitcoin [9], such as 51% attacks. It is rather difficult for a 
stakeholder to resist the temptation of high profits claimed by 
these proxies. As a result, we can see that with the passage of 
time, the majority of the voting weight becomes concentrated 
in voting proxies. Similarly, the phenomenon that the mining 
power is concentrated in mining pools also exists in Bitcoin 
and Ethereum, which are relatively mature platforms now. 

In addition, the cost of voting manipulation is low since 
each voter can vote for up to 30 block producer candidates 
at the same time with no reduction in the voting weight that 
each candidate can receive. Not surprisingly, we can observe 
that there are some abnormal voting gangs with similar voting 
behaviors or mutual voting behaviors in the analysis. These 
anomalies are obviously driven by interests and are closely 
related to the design of the incentive mechanism of EOSIO. 
Therefore, the root cause of the oligopoly trend and voting 
anomalies is closely related to the system design and not 
necessarily related to the bootstrapping phase of EOSIO. 

Q2: Are there any mechanisms to adjust the DPoS con- 
sensus mechanism and make the system more decentralized? 

First, voters in EOSIO only account for a small fraction of 
stakeholders, and their voting power is distributed unevenly. 
This means a few voters possessing a large number of stakes 
are sufficient to centralize the network. Furthermore, as we dis- 
cussed earlier, each voter can vote for multiple block producer 
candidates at the same time with no discount on the voting 
weight, which leads to a low cost of voting manipulation. 
Therefore, except to encourage the stakeholders to be active 


3https://coinmarketcap.com/currencies/eos/ 
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in the governance of EOSIO, the community can also look 
for a more reasonable value for the number of votes allowed 
per account. Existing work [28] has studied how to find the 
optimal number of votes allowed per account in DPoS with the 
governance game. Moreover, another possible solution can be 
the introduction of an attenuation coefficient when a user votes 
for multiple candidates. In this manner, a voter can assign 
different voting weights to the multiple chosen candidates 
based on their ratings. 

Second, the voting weights in EOSIO are increasingly 
concentrated in voting proxies, and the block production is 
also centralized in a small group of block producers with 
little variation. This fact makes the system rather vulnerable 
to centralized control and malicious attacks. For example, 
Xu et al. [7] proposed a type of voting attack executed by 
block producers—the block producers can collude to blacklist 
the voters with large stakes which will threaten the authority 
of the block producers themselves. Moreover, in our analysis, 
we reveal some abnormal voting gangs working in collusion. 
To tackle this problem, we notice that some researchers have 
proposed a theory-based reward and punishment incentive 
mechanism for DPoS to improve the voting enthusiasm of 
nodes and deal with the voting anomalies in the system [29]. 
In addition, our analysis method can also help voters investi- 
gate the voting behaviors of voting proxies and block producer 
candidates before making a choice. 


VII. RELATED WORK 


We present the related work in this section, which 
mainly includes the decentralization analyses of DPoS-based 
blockchain systems and existing analyses in EOSIO. 


A. Decentralization Analysis of DPoS-Based Blockchains 


Decentralization is an important characteristic that can 
tell blockchain systems from traditional centralized systems. 
At present, there have been some studies on analyzing the 
decentralization of blockchain systems. Most of the existing 
research pointed out that Bitcoin and Ethereum have not 
achieved true decentralization in terms of mining power, 
network resources such as bandwidth, etc., [9], [30], [31]. 
Since PoW-based blockchains become more and more cen- 
tralized, Chen ef al. [10] proposed tools to timely quantify 
the decentralization in terms of mining power in PoW-based 
blockchain systems. DPoS-based blockchains, on the other 
hand, do not require every node in the network to directly 
participate in block production. Instead, users can vote for 
a specified number of block production candidates, and the 
elected block producers generate blocks in turns. Thus in 
DPoS-based blockchains, the mining power is a weak influ- 
ence factor of decentralization. 

For DPoS-based blockchain systems, Jeongy [28] explored 
the relationship between decentralization and the number of 
votes allowed per account and found that the “one vote per 
account” rule for centralization mitigation may not be neces- 
sary. Rebello et al. [32] analyzed several quorum-based con- 
sensus protocols including the EOSIO protocol and pointed out 
some clear vulnerabilities of these protocols. Kwon et al. [19] 
measured the degree of decentralization in several blockchain 
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systems based on PoW, PoS, and DPoS with the entropy metric 
and explain why it is difficult to design a fully decentralized 
system. Li and Palanisamy [20] conducted a comparison 
of decentralization between Bitcoin and Steem [33], which 
are based on PoW and DPoS, respectively. They found that 
compared with Steem, Bitcoin tends to be less decentralized 
in general and more decentralized among top stakeholders 
via some distributions and the entropy metric. However, there 
is a lack of in-depth analyses studying the decentralization 
evolution and uncovering the abnormal voting phenomena in 
DPoS-based systems. 


B. EOSIO Analysis 


Existing studies on blockchain systems cover several aspects 
including blockchain architecture and performance [1], [7], 
privacy and security [34]-[37], smart contracts and transac- 
tions [38]-[41], etc. As one of the earliest and most typical 
DPoS-based blockchain systems, EOSIO has received atten- 
tion of scholars these years. 

In terms of architecture and security, Xu ef al. [7] pro- 
vided a comprehensive analysis on EOSIO’s architecture, 
performance, and economy. Lee et al. [42] introduced four 
attacks in EOSIO, whose root cause lies in the character- 
istics of EOSIO. Quan et al. [17] proposed a static analysis 
tool to detect the fake-transfer vulnerabilities of EOSIO’s 
smart contracts. He et al. [16] proposed a tool that can detect 
four popular vulnerabilities in EOSIO smart contracts at 
the WebAssembly code level. Lee and Lee [43] proposed 
a kind of attack that can disturb the fairness of incen- 
tive policy by manipulating the block production schedule 
in EOSIO, and this attack can bring additional rewards or 
losses to block producers. In terms of blockchain transac- 
tion analysis, Huang et al. [8] investigated EOSIO and the 
associated DApps via measurement study. With a focus on 
security issues, they discovered some real-world attacks and 
developed detection techniques for fraudulent activities in 
EOSIO. Zheng et al. [18] performed a statistical analysis on 
seven well-processed datasets in EOSIO, and outlined some 
possible research directions based on the proposed datasets. 
Zhao et al. [14] abstracted the records of four major activities 
in EOSIO as complex networks [44], [45] and obtained some 
interesting observations via network metric analysis. However, 
none of them quantify the decentralization characteristic and 
investigate the abnormal voting phenomena based on the real 
transaction data in EOSIO. 


VIII. CONCLUSION AND FUTURE WORK 


This article performed the first decentralization evolution 
study on EOSIO, a typical DPoS-based blockchain system. 
We analyzed how EOSIO gradually evolves from decen- 
tralization to oligopoly by characterizing the activities of 
voters, voting proxies, and block producers participating in 
the DPOS consensus process, and obtained many insightful 
findings. Moreover, we put forward methods to discover the 
abnormal voting gangs with similar voting behaviors and 
mutual voting behaviors. Some suspected voting manipula- 
tion phenomena have been revealed in our analysis. Besides, 
we discussed the root cause of the oligopoly trend and the 
mechanisms for enhancing the decentralization of EOSIO 


Ii 


according to the analysis results, which can also provide a 
reference for other DPoS-based blockchain systems. 

For future work, we will expand our study in two directions. 
First, there may exist other complex abnormal voting patterns 
needing to be explored, we plan to investigate more abnormal 
voting phenomena in the system by combining the token 
trading data and the resource trading data in EOSIO. Second, 
we want to extend this analysis to blockchain systems with 
other voting-based consensus algorithms, and build a decen- 
tralization monitoring platform to timely quantify the degree 
of decentralization and capture the abnormal phenomena in 
these systems. 
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